1. Technical Field
The invention relates to a method of handling control information in a packet-based communications network, to a network component of such a communications network, and to communications systems comprising this network component. In particular, the invention relates to handling of control information sent inband with traffic data in a packet-based communications network.
2. Description of the Prior Art
In traditional synchronous communications networks control information is often sent inband, i.e., on the same logical channel as traffic data (traffic channel), to allow the control information to take effect at a receiving side as fast as possible. Carrying control information inband together with traffic data ensures that the control information arrives at the receiving side at exactly the same time as the traffic data which have been generated at the same point in time as the control information. The same applies if earlier generated control information still represents the latest status and is therefore being sent together with the traffic data to be transmitted next.
The main idea behind the concept of sending urgent control information inband with traffic data is the fact that the traffic channel (and often only the traffic channel) provides real-time transmission capability due to the real-time requirements of the underlying application like interactive video or interactive voice. Generally, inband control information can be sent on a specific traffic channel either on a regular basis or by stealing bandwidth on demand in the case of very urgent control information.
The control information sent inband with traffic data can relate to various control-purposes. For example, the inband control information can serve in a communications network for a remote control of an encoding rate to be used at an opposite receiving side. Such an encoding rate control allows a rapid adaption for example to a varying radio quality or to varying bandwidth constraints.
The remote control of the encoding rate is already incorporated in new speech coding concepts such as Adaptive Multi-Rate transmission (AMR, GSM 06.71 version 7.0.2, Release 1998, Digital cellular telecommunications system (Phase 2+); Adaptive Multi-Rate (AMR); Speech processing functions; General description) or in Enhanced Variable Rate Codec transmission (EVRC, TIA/EIA/IS-127, Sep. 9, 1996, Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems). The term “codec” designates a combination of an encoder and a decoder connected in series.
The speech coding concept of AMR, which was originally developed for synchronous communications networks, incorporates a remote control of a codec mode. Multirate adaption of encoding and decoding rates in accordance with AMR is based on quality measurements of the radio channel. The measurements are processed to give an uplink (UL) quality indicator and a downlink (DL) quality indicator. The UL quality indicator is mapped onto a UL codec mode command and the DL quality indicator is mapped onto a DL codec mode request (CMR). UL codec mode and DL CMR are sent as inband signals in the UL radio channel. DL codec mode and UL codec mode command are sent as inband signals in the DL radio channel.
The speech coding concept of EVRC also incorporates a remote control of encoding and decoding rates. Instead of using a CMR which is to be fulfilled, EVRC utilizes a control command which can be regarded as a “Reduce Rate Request” (RRR). The RRR is being sent until an opposite side (which is not necessarily physically separated from the sender) receiving the RRR has transmitted enough frames at a lower rate, thus providing some bandwidth for dim and burst signaling.
Existing AMR and EVRC applications in synchronous networks like the Global System for Mobile communications (GSM) or the IS-95 system use either inband or out-of-band concepts for rate control. New generation communications networks support packet-based transmission. In the case of packet-based transmission, control information like CMRs or RRRs is preferably sent inband with traffic data for mainly two reasons. First, several packet-based communications network concepts support priority-setting depending on the type of the transmitted data. Traffic data in general have real-time priority. Therefore, the fastest way to transport urgent control information is always inband on the channel. Second, co-locating traffic data and control information on the same traffic channel simplifies interoperability in the case that a communication involves several types of networks. In this case, a conversion between traffic data formats and/or protocol formats at one network type's boundary would not or not significantly effect the contents of the traffic channel. Furthermore, the original time relation of traffic data and control information is kept.
Although packet-based communications networks have several advantages, such networks also suffer from serious drawbacks. For example, packet-based communications networks like networks operating in accordance with the Internet Protocol (IP) do not always offer a defined quality-of-service that is high enough for all types of applications. IP networks such as the public Internet often involve problems like packet loss, network jitter in the form of time-varying delays and out-of-sequence packets and congestions leading to delays. To cope with these problems, techniques such as the Real-Time Protocol (RTP) and jitter buffers have been developed.
RTP is specified in the Internet Engineering Task Force (IETF) documents RFC 1889; RTP: A Transport Protocol for Real-Time Applications, Request for Comments: 1889, January 1996 and RFC 1890; RTP profile for Audio and Video Conferences with Minimal Control, Request for Comments: 1890, January 1996, published in the Internet (http://www.ietf.org). RTP is a real-time transport protocol which provides end-to-end network transport functions suitable for applications transmitting real-time data in the form of RTP packets. Usually, applications run RTP on top of the User Datagram Protocol (UDP) to make use of the UDP's multiplexing and checksum services. Both protocols contribute parts of the transport protocol functionality. However, RTP may also be used with other underlying network or transport protocols.
RTP provides several services like sequence numbering, which tells a receiving side if the packets are arriving in sequence or at all, time stamping and delivery monitoring. However, RTP itself does not provide any mechanism to ensure timely delivery, to prevent out-of-order delivery or to provide other quality-of-service guarantees. Therefore, RTP is often combined with jitter buffers as described in WO 00/42749.
Jitter buffers are memories which are used for sorting received packets into the correct sequence and for delaying the buffered packets as needed to compensate for variations in network delay. The above RTP specification RFC 1889; RTP: A Transport Protocol for Real-Time Applications, Request for Comments: 1889, January 1996 discusses such inter arrival jitter in section 6.3.1 and in appendix A.8.
Each received packet is usually buffered such that it is aligned with the packets already stored in the jitter buffer. This means that packets arriving out-of-sequence are aligned relatively to the current buffer contents and inserted in the appropriate buffer position. In the course of this, however, the buffer algorithm may determine that a received packet is already too old to be aligned with earlier received packets already stored in the buffer. In this case the received packet is discarded. If the current network-jitter situation allows, the buffer size is adaptively reduced to decrease the buffer delay by discarding one or possibly more stored packets.
Although the use of a jitter buffer has several advantages, buffering of packets has the drawback that the processing of the packets is delayed. Therefore, any control information contained inband in the packets will also be buffered and will be available for control purposes only with a certain delay, i.e., the control information will take effect delayed. Moreover, in the case of packet loss the control information comprised within a lost packet will not take effect at all. In such a case it has been-proposed for networks employing EVRC to continue to operate as indicated by the control information comprised within the last packet received (RTP-EVRC; An RTP Payload Format for EVRC Speech, Internet Draft of the Internet Engineering Task Force; May 8, 2000; Expires: Nov. 8, 2001, section 4.1)
However, this suggestion can not solve the discussed problems satisfactory. The reason therefore is the fact that packets may arrive out-of-sequence so that earlier sent packets arrive later than packets sent later. This means that the last received packet is not necessarily the newest packet, i.e. the packet most recently generated or sent, amongst the packets that yet have been received. It may even be too old to be aligned with the packets stored in the buffer and may thus be discarded by the buffer algorithm.
There is a need for a method of handling in a packet-based communications-network control information sent inband with traffic data, the method allowing to cope in a reliable manner with control information delay and out-of-date control information. There is also a need for a network component of a packet-based communications network operating in accordance with such a method and communications systems comprising this network component.